fix(ui): show-in-folder button does nothing on macOS#94
Open
miguelAngelo1999 wants to merge 1 commit into
Open
fix(ui): show-in-folder button does nothing on macOS#94miguelAngelo1999 wants to merge 1 commit into
miguelAngelo1999 wants to merge 1 commit into
Conversation
The revealItemInDir() from @tauri-apps/plugin-opener fails silently on
macOS because dunce::canonicalize() errors if the file doesn't exist,
and NSWorkspace::activateFileViewerSelectingURLs fails without surfacing
errors to the JS side.
Replace all revealItemInDir() calls with invoke('open_file_location')
which uses 'open -R' on macOS, 'explorer /select,' on Windows, and
xdg-open on Linux — all existing implementations in history.rs.
Also improved open_file_location to fall back to the parent directory
if the exact file no longer exists (e.g. renamed after download).
Affected: QueueItem, UniversalQueueItem, GalleryQueueItem, ChatPanel,
HistoryDialog, ProcessingContext
anhtahaylove
added a commit
to anhtahaylove/youwee
that referenced
this pull request
Jul 3, 2026
The Tauri opener reveal helper is unreliable on macOS in upstream PR vanloctech#94, and the app already has a platform-aware Rust command for opening file locations. Queue and processing UI now reuse a tiny frontend helper that calls that command instead of duplicating opener behavior. Constraint: Keep the port small and avoid upstream PR vanloctech#94's large ProcessingContext rewrite. Rejected: Port PR vanloctech#94 wholesale | it pulls more than 1000 lines of unrelated ProcessingContext churn. Rejected: Keep per-component revealItemInDir calls | the existing Rust command is the shared platform boundary. Confidence: high Scope-risk: narrow Directive: Use openFileLocation for future file reveal buttons instead of importing revealItemInDir directly. Tested: bun run biome check --write . Tested: bun run tsc -b Tested: bun test Tested: cargo check in src-tauri Not-tested: macOS Finder reveal behavior on this Windows machine.
Owner
|
Thanks for the fix. I agree the macOS “Show in Folder” issue is worth addressing, but this PR cannot be merged as-is because it includes a lot of unrelated and stale changes. The PR removes Could you please rebase on the latest |
vanloctech
pushed a commit
that referenced
this pull request
Jul 3, 2026
The frontend still called the opener plugin directly in several queue and processing surfaces even though the backend already exposes an open_file_location command with platform-specific reveal behavior. This keeps the UI on the app command boundary while avoiding the broader ProcessingContext rewrite from the larger upstream PR. Constraint: Upstream already registers open_file_location in Rust, so the frontend can reuse that command without adding backend surface area. Rejected: Port PR #94 wholesale | it pulls a larger ProcessingContext diff than needed for the Windows reveal fix. Confidence: high Scope-risk: narrow Directive: Keep file reveal UI actions routed through this helper unless the backend command is removed or renamed. Tested: biome targeted check for changed files; bun run tsc -b; cargo check in src-tauri after restoring the bundled yt-dlp binary; manual Show in folder on Windows custom build with a real downloaded sample-5s.mp4 file. Not-tested: macOS Finder reveal behavior; full Biome check in the clean Windows PR worktree because unrelated CRLF diagnostics affect untouched files.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Show in Folder / Open Folder button on completed download items does nothing on macOS. Clicking it silently fails with no feedback.
Root Cause
All queue item components (
QueueItem,UniversalQueueItem,GalleryQueueItem,ChatPanel,HistoryDialog,ProcessingContext) were usingrevealItemInDir()from@tauri-apps/plugin-opener. On macOS this fails silently because:dunce::canonicalize()throws if the file doesn't exist on diskNSWorkspace::activateFileViewerSelectingURLserrors are not surfaced to the JS layercatchblock only doesconsole.error— no user feedbackFix
Replace all
revealItemInDir()calls withinvoke('open_file_location')— the existing Rust command inhistory.rsthat uses platform-native commands:open -R <path>(reveals in Finder)explorer /select,<path>xdg-open <parent dir>Also improved
open_file_locationto fall back to the parent directory if the exact file no longer exists (e.g. renamed after download), instead of returning an error.Files Changed
src/components/download/QueueItem.tsxsrc/components/download/UniversalQueueItem.tsxsrc/components/download/GalleryQueueItem.tsxsrc/components/processing/ChatPanel.tsxsrc/components/processing/HistoryDialog.tsxsrc/contexts/ProcessingContext.tsxsrc-tauri/src/commands/history.rs